Relación N:M a dos FK como clave primaria compuesta

¿Qué es una relación N:M?

Una relación N:M (muchos a muchos) ocurre cuando:

• Un registro de la tabla A puede relacionarse con muchos registros de la tabla B.
• Y un registro de la tabla B puede relacionarse con muchos registros de la tabla A.

Ejemplo clásico

Esto NO puede representarse directamente en SQL con una sola FK.

Por eso aparece una tabla intermedia

Matricula
---------
id_alumno
id_curso

¿Qué identifica realmente una fila?

La pregunta clave es:

No es un número inventado.

Lo que realmente identifica la fila es:

• Qué alumno.
• En qué curso.

Por tanto

PRIMARY KEY (id_alumno, id_curso)

La combinación de ambas claves foráneas ya es única.

Eso significa que:

• No necesitas otra clave artificial.
• Evitas duplicados automáticamente.
• El modelo es más lógico.

¿Qué ocurre si usas una PK artificial?

Muchas personas crean algo así:

CREATE TABLE matricula (

 id_matricula INT PRIMARY KEY,
 id_alumno INT,
 id_curso INT

);

Problema

SQL solo controla que id_matricula no se repita.

Pero NO controla duplicados lógicos.

Ejemplo

1 | 14 | 3
2 | 14 | 3

Para SQL son filas distintas.

Pero en el mundo real:

¿Cómo se arregla?

ALTER TABLE matricula
ADD CONSTRAINT uq_alumno_curso
UNIQUE(id_alumno, id_curso);

Al final acabas teniendo:

• PK artificial.
• UNIQUE adicional.
• Dos índices.
• Más complejidad.

Ejemplo correcto con PK compuesta

Tablas principales

CREATE TABLE alumno (

 id_alumno INT PRIMARY KEY,
 nombre VARCHAR(50)

);

CREATE TABLE curso (

 id_curso INT PRIMARY KEY,
 nombre VARCHAR(50)

);

Tabla intermedia

CREATE TABLE matricula_compuesta (

 id_alumno INT,
 id_curso INT,
 fecha DATE,

 PRIMARY KEY(id_alumno, id_curso),

 FOREIGN KEY(id_alumno)
 REFERENCES alumno(id_alumno),

 FOREIGN KEY(id_curso)
 REFERENCES curso(id_curso)

);

Inserción válida

INSERT INTO matricula_compuesta
VALUES (1, 10, '2024-09-01');

Duplicado

INSERT INTO matricula_compuesta
VALUES (1, 10, '2024-09-15');

¿Cuándo sí tiene sentido una PK artificial?

Cuando la tabla intermedia tiene vida propia.

Ejemplo real

CREATE TABLE detalle_pedido (

 id_detalle INT PRIMARY KEY,

 id_pedido INT,
 id_producto INT,

 cantidad INT,
 precio NUMERIC(10,2),
 descuento NUMERIC(10,2)

);

Aquí cambia el escenario

• La fila tiene atributos importantes.
• Puede repetirse el mismo producto.
• Hay descuentos distintos.
• Puede haber promociones.

Entonces

La fila sí representa una entidad propia.

PK compuesta vs PK artificial

Ejemplos de PK compuesta

• Alumno ↔ Curso
• Usuario ↔ Rol
• Actor ↔ Película

Ejemplos de PK artificial

• DetallePedido
• Históricos
• Asignaciones con fechas

Casos prácticos explicados

Usuario ↔ Rol

PRIMARY KEY(id_usuario, id_rol)

Un usuario no debería tener el mismo rol dos veces.

Profesor ↔ Departamento

Aquí suele usarse PK artificial.

¿Por qué?

Porque puede existir histórico:

7 | 3 | 2023
7 | 3 | 2025

El mismo profesor vuelve al mismo departamento en otra fecha.

Entonces

id_asignacion INT PRIMARY KEY

Regla mental definitiva

Usa PK compuesta cuando:

• La tabla solo relaciona entidades.
• No tiene identidad propia.
• No hay histórico.
• No hay múltiples variaciones.

Usa PK artificial cuando:

• La tabla tiene datos propios importantes.
• Existe histórico.
• Puede repetirse la combinación.
• Necesitas referenciar filas individuales.